[レポート]クラウド上でミッションクリティカルなシステムを「運用」するには 〜重要課題「運用」について考える〜 #AWSSummit
クラウド上でミッションクリティカルなシステムを「運用」するには 〜重要課題「運用」について考える〜
6/1 (水) ~ 6/3 (金) に開催された AWS Summit Tokyo 2016 のセッション "クラウド上でミッションクリティカルなシステムを「運用」するには 〜重要課題「運用」について考える" を聴講しました。本記事はそのレポートです。
セッション
スピーカー
TIS 市田真也 様
大事なこと
今日は3つ覚えて帰る
背景
TISとは
- 創業45年のシステムインテグレータ
- 旧三和銀行系からの金融、それから基幹系システム
- グループ全体で2万人
- 東京、名古屋、松本、九州‥
- データセンターも11箇所(日本と中国)
- 基幹系+クラウドや仮想化にも力を入れている
1.ミッションクリティカルとは
クラウドに乗せるのは
- 情報システムや基幹システム
- 今回は基幹システムの話し
基幹システムとは
- ERPを中心としたシステム
- ダウンすると社会的影響がある
- ERPに限らず業務やサービスの中心になるシステム
- 24/365 止まらない
損失は?どれくらいの停止なら許されるか?
- それによってどこまで運用を手厚くするか決まる
ミッションクリティカルな運用の実現に必要なもの
- 可用性 システム全体としての可用性
- 保守性 パッチを当てるなどする際に止める必要があるかどうか
- セキュリティ
- 性能
- 拡張性 拡張する際にシステムを止める必要があるか
上記は主に開発時に設計させる、これをいかに維持していくかが運用のポイント
2. ミッションクリティカルな運用とは
運用設計
- 運用のための設計の各項目はフレームワークとして用意している(100項目くらいありそう)
どこまで不測の事態を想定するか
- 本番作業をする際は
- 手順書、セキュアルーム、認証、ペア、ログ、エビデンス、フォールバックポイント・手順、エスカレーション、のルールを定めている
- 主観的な判断ではなく、ある時間になったらフォールバックするなどの基準を用意してそれを元に担当者が判断できるようにしている
- ペア作業・セキュアルームは文化になっている
内部の人がデータを持ちだそうとしたら
- 認証・ペア作業・セキュアルームなど持ち出し出来ない仕組みとしている
障害が発生したら
- 連携フロー図に従って連絡 第一連絡先、第二連絡先、第三…
- 障害対応指揮所が直ぐに作られる
- ホワイトボード半分に時系列の状況
- もう半分は何が原因か何が起こったかなどを書く
- 最後に障害報告書そして再発防止策
お客様からの障害連絡があったら
- 全てサービスデスクで受ける、インシデント管理を行う
停電したら
- 場所はオフィス、監視センター、変電所からの送電
- UPSが用意されているか、DCの場合は別ルートで複数電源が供給されているか
万が一大規模災害が起こったら
- システムのDR、運用のDR
- 運用DRも考えないとビジネスが回らない
- 東京と大阪で運用できるなど
〜どこまで不測の事態を想定するか〜
ミッションクリティカルな運用に必要なもの
- 運用設計
- 運用フレームワーク
- 設備
- 人・体制
- ノウハウ
3. クラウド上でミッションクリティカルな運用をするには
クラウド運用で変わるもの
- ハードウェア運用
- 無くなる
- リソースコントロール
- 新たに考慮すべきところ
- ネイティブサービス
- 特性に沿った運用が必要
- APIによる自動化
- 課金管理
クラウド運用で変わらないもの
- OSより上のレイヤーの運用
- 業務運用
- 人・体制
- 運用設計
- 運用フレームワーク
- 既存の運用を踏襲した上で更に効率化を目指すのが大事
クラウド運用でより大事なもの
- セキュリティ
- 管理コンソール
- Webの世界に出ているので
- 責任分界点
- 物理的・論理的な境界
- PCIDSS
- 管理コンソール
クラウド上でミッションクリティカルな運用なもの
- 既存運用+クラウド運用
- 実は既存の運用とそんなには変わらなくてもよい。もっと効率化出来るところが出てくる。
コマーシャルの時間
- TISでは東京大阪でデータセンターと運用部隊を用意している
- 最近は情シスだけではなく事業担当もクラウドを使っていてガバナンスが効かない
- オンプレ/クラウド、部署間のシステムを統合管理をしている
まとめ
- ミッションクリティカルは甘くない
- 是非いまの運用を振り返ってみてください
感想
ミッションクリティカルな運用って何を考えてどんなところまでやってるんだろう、という純粋な興味を持って参加しました。
運用のレベルが1〜10まであるとしてレベル8以上の運用を考えた場合、どういった事を考えているという事が分かり大変参考になりました。例えば基幹系ではなく情報系システムなどであればそこから引き算をして適切な運用レベルまで下げるなど考えられます。ビジネスに必要な運用レベルとコスト、スピードとのトレードオフをしっかりと認識して運用に落としこむ事が重要と感じました。